The Third Generation Partnership Project (3GPP) and Third Generation Partnership Project 2 (3GPP2) have developed sets of specifications that describe a flexible Next Generation Networking (NGN) architecture for implementing Internet Protocol (IP) based telephony and rich multimedia services over next generation packet-based networks as well as traditional circuit-switched networks. The architecture is referred to as an IP Multimedia Subsystem (IMS) and effectively provides centralized control of IP based telephony and multimedia services to users that are supported by different packet-switched (PS) and circuit-switched (CS) access networks. The access networks may be wired or wireless and may include local area networks, cellular networks, wireless local area networks, cable networks, public switched telephone networks, and the like. As such, service providers are able to provide and control services from a common platform independent of the type of access network that is serving the users.
The services provided by IMS are generally referred to as IMS Centralized Services (ICS) and some are set forth in the 3GPP TS 23.292 V8.0.0 technical specification, which is incorporated herein by reference in its entirety. This technical specification specifies the architectural requirements for delivery of consistent IMS services to a user regardless of the type of access network. When using a PS access network that is capable of supporting full-duplex voice communications, the PS access network is used to establish a packet-switched bearer path to carry media for IMS sessions, as set forth in the 3GPP TS 23.228 technical specification, which is also incorporated herein by reference. When using a CS access network or a PS access network that does not support full-duplex voice communications, the CS access network and associated CS core network are used to establish a circuit-switched bearer path to carry media for IMS sessions. ICS provides mechanisms to use the circuit-switched bearer paths in the CS access networks for IMS sessions as well as provide service control and continuity when using these circuit-switched bearer paths for IMS sessions.
While establishing and controlling IMS sessions supported by PS access networks that support voice communications are relatively straightforward, significant complexities arise when establishing and controlling IMS sessions via CS access networks. When the bearer path for an IMS session is provided by a CS access network, a transparent control channel is established between the ICS capable user terminal and the IMS. If the user terminal is not ICS capable, the control channel will extend between the IMS and a service node, such as an ICS enhanced mobile switching center (MSC) that operates as an ICS client on behalf of the user terminal. The control channel is generally referred to as a service control channel, and is used by the IMS to provide IMS services and control IMS sessions when those IMS sessions have a bearer path provided in the CS access network.
Although the bearer path for an IMS session may be supported by a CS access network, the service control channel may be provided via the CS access network or, if available, a PS access network. When the service control channel is provided by the PS access network in these instances, it is generally assumed that the PS access network will not support voice communications, but is capable of supporting the exchange of information between the user terminal, or an agent thereof, and the IMS. In either case, the service control channel is separate from a CS bearer control signaling channel that is used to establish and control the portion of the bearer path that extends through the CS access network. Currently, the service control channel must be established and associated with the CS bearer signaling channel when IMS sessions are established, even if the IMS sessions do not initially invoke IMS services. Establishment, and in particular, the association of the service control channel and the CS bearer control signaling channel is time consuming and often unnecessary for basic voice calls. The time associated with establishing and associating these channels delays call setup, and when IMS services are not invoked during the session, wastes resources.
Accordingly, there is a need for a mechanism to add an associated service control channel for an IMS session when an IMS service is required. There is a further need to allow initiation of an IMS session that employs a CS bearer path without associating a service control channel with the IMS session, and subsequently adding a service control channel for the IMS session when IMS services are needed.